旅botミニを公開しました 7.海の真ん中に、まぁメイドさんのお家を作る
2025年2月25日 00:16
旅botミニの続きです。
これについては作っているものが旅botミニからかなり拡張することになったので旅botミニの応用として公開すべきなのか少し迷っています。
なのでとりあえず最初の構想からどのように展開したのかをここで書いて、このシステムそのものは別途新しい記事に分けて今後の記述をしたいと思います。
思いつきはGoogle Map APIの置き換え
旅botそのものも面白いものですし応用のトランスフォーマーバトルも結構面白いと思っているのですが、作ってるうちに
Google Map APIを別物に置き換えたら、別の仮想世界を旅できるのではないか
と思いついたのです。
それにGoogle Map APIも旅botで遊ぶくらいならほとんど料金はかからないものの、有料APIなので登録も設定も結構大変です。何か手軽に使える代替APIはないものか考えていたのです。
無料のMap API/地図データというといろいろ考えられます。調べてみると
OpenStreetMap OpenStreetMap is a map of the world, created by people like y www.openstreetmap.orglink
Home - Overture Maps Foundation overturemaps.orglink
などもあります。
日本限定だと公的な地図プロジェクトもあるようです。
PLATEAU [プラトー] | 国土交通省が主導する、日本全国の3D都市モデルの整備・オープンデータ化プロジェクト 国土交通省が主導する、日本全国の3D都市モデルの整備・オープンデータ化プロジェクト「PLATEAU」。データを活用するため www.mlit.go.jplink
さすがにStreet View的にあちこちの風景写真があるのはGoogle Mapくらいかな。これは本当にすごい(でも維持が大変そう)ものだと思います。
PLATEAUだと都市3Dモデルまであるので、都市限定だと3D画面まで作れる(ただし灰色ポリゴン)
仮想世界の旅と考えるとMMOゲーム世界やMinecraft世界なども考えられるかもですね(そういえばSecond Lifeはやったことないですがその頃誰か同じようなことは考えてないのでしょうか)
そういう空間を緯度経度に投射して3Dビューを接続してGoogle Map APIっぽくすれば、今の旅botでもそういう空間を旅できるかもですね。
ただ前にも書いたように、AIにとっては他人が作った仮想空間の知識は現実の地図知識より小さいでしょう。
「代わりに新子安駅などどうでしょう」みたいな気の利いた会話は現状では限定的でしょうね。
MMOゲームとかは企業がお金かけてやってるので、その企業側に任せたほうがよいでしょう。工数かけてAIにゲーム空間知識とか学習させていそうですし。
とりあえず3D画面は後で考えるとして、代替物は出来るだけ多くあったほうがよいと思っているので、既存実装の「なんちゃってGoogle Map API互換の小さなサーバー/SaaS」を建てればお手軽にアクセス出来るのではないかと思って調べ出しました。
海の真ん中に まぁメイドさんのお家を建てる
実際に各Map APIやデータを調べてみると、そう簡単には置き換えとはいかなそうということは見えてきました。むしろ専用にAPIを作り直したほうが楽なくらい(でもそのうちやるかも)
意外だったのは「Google Map API類似の手順で地図情報を配信するような部品が見つからなかった」ことです。
単純に探し方が悪かったのかもしれないけど、「Google Map API」をアクセスする部品はnpmにもUnity Asset storeにも山ほどあるのですが、地図データ/3DデータをGoogle Map APIに類似したAPIで配信する部品というのが見つからない。。
まぁ元々需要が少ない(and地図データを持っている大元は限られる、andきっと権利問題でお互い手を出さない)みたいな話なのでしょう。
でも完全互換という話でなければ複雑ものではないので、ここは旅botが使う部分だけのAPIを手作りしてもよいかな、と考えて準備を始めました。
久しぶりにUnityをアップデートして、Blenderを再インストールして、他に使える部品がないか探しながら準備しました。
どうせオリジナルの地図を配信するというのなら最初は大きい(andどこかで権利問題が付いてきそうなオープン地図)データを使うより、小さな家の地図と3Dデータを作ろう。ということで
まぁメイドさんのお家を海の真ん中に作ろう
ということにしました。
場所はとりあえず緯度経度が割り切れる数字のほうが計算しやすいので 「緯度30,経度130」としました。屋久島の先のあたりですね。
まぁメイドさんのお家は緯度30,経度130 (Google Mapより)
お家用に使えそうなフリーの3Dアセットをいくつか探しました。
Unityは仕事の案件で何回か使ったことがあるのでそこそこには慣れているのですが、Unityはクライアント向けのツールなのでサーバーをやらせるのにはちょっと筋が違うかもです。
Marmaid Server上のまぁメイドさんの町/お家をClaude Desktopでアクセスする
どうせならサーバーもクラウドに載せたいですがそのままではVMでデプロイになるのでコストがかかります。。
軽量にデプロイならさすがにもっとシンプルな仕組みということでthree.jsでなんとかならないか検討しました。
three.jsは元々Webブラウザ上で動く前提のクライアントツールで、3Dレンダリングをサーバーで行うのには向かない。でもヘッドレスでレンダリングする方法はあるらしい。なんとかヘッドレス描画で一応画像ファイルに描画できたけど、この手のごり押しレンダリングだとテクスチャーの描画やライトが無茶苦茶になることも多いという記憶もあるな。。
などと考えているうちに、ちょっと思ったのです。
AI応用らしくないな。。
なんちゃってGoogle Map APIであらかじめ作った経路情報と3D画像をAPIで渡すだけなら手間は別として確実に作れるだろう。
技術的に問題点はない。
この方向で作ってもきちんと面白いものは出来る。
旅botミニの応用例2としてならそこまでがきれいだと思ったのですが、なんか面白みがないなと。
サーバーは「『何があるか』しか管理しない」
いろいろ考えたあげく、次のような構成に考え直しました。
Prompt Serverは画面に映る物の様子のプロンプトを返す
サーバーは「ある座標に物がある」という情報しか管理しない。旅botからbotが存在する座標とカメラ方向の情報を受け取る。その座標から何が見えているかという情報のテキストだけを作り、そのテキストをClaude Desktopに返す。旅botミニでは受け取ったテキストをプロンプトとして画像生成AIを使って、画面を再生する。
結果として各Claude Desktopで見える画面は個々の画面でまったく異なります。でも「テーブルがあって椅子があってTVがあってカップがある」という画面は同じです。意外とそれで困らないのではないか。
同じClaude Desktopの画面でも、見るたびに画像は異なります。それは不自然かもしれませんが、「テーブルがあって椅子があってTVがあってカップがある」という画面は同じです。動画なら違和感が強いかもしれませんが、常に視点が移動する旅botでは思ったより困らないのではないか。
テーブルがある、椅子がある、カップがある、TVがある…というプロンプトだけで画面を作る
自分が見る画像については確かに一貫していて欲しいとは思うのですが、見える画像の一貫性は今の画像生成AIではまだ安定しませんが、動画生成AIが急速に進化している状況を見る分に、近いうちに一貫性も十分保たれるようになると予想します。
たしかずっと以前に「画像を通信で送るより、画像を生成AIのプロンプトとして変換して送れば、超圧縮になるのでは」みたいな記事をどこかで見た記憶があるのですが、そのとき見た記事がどれだったかわからないんですよね。。まぁそれの応用と言えるかもです。
画材をサーバーに置かないという考え方の上ではMMOゲームの仕組みにも近いです。
見える画像が一貫性を保てない点だけを除けば、技術的にはメリットだらけです。
アセット画像ファイル、3Dモデルデータ、動画だとしてもリグ/モーション情報なども一切作成/管理しなくてよい
通信はデータ量が多い画像はなくなり、少ないテキストのみ。
サーバーは画像生成/合成処理は一切しなくてよい。テキストだけの処理で済むので多数のクライアントをつないでも負荷が小さい。
3D画像でよく問題になるオブジェクトの前後関係問題、ライト、カメラの問題がほとんどなくなる(実際には視野管理の前後や位置関係情報はあるが処理は全然軽くなる)
表示上のオブジェクトの配置関係性やその表示は画像生成AI側がよしなに生成してくれる。
シビアな用途以外では、他の人が見る画像と自分が見る画像が一致しないことは思ったほどに重要ではないと考えています。人は皆自分の主観を中心にしてお互い違うものを見ているのですから。
Claudeは「パンあれ」と言われた。するとパンがあった
ここまでは旅botミニの応用案を拡張したまでなのですが、考えているうちに全然別種類のメリットが見えてきました。
地図空間内のデータがテキストだけで済むということは、データが非常に単純なので、追加と削除も単純ということです。つまり
dbに「name:パン,緯度:xx,経度:yy」と位置情報を追加するだけでパンが現れる
ということです。
パンがあるというテキスト情報をdb追加する
削除も同じです。まぁ削除だけなら3D画像を生成するサーバーでも削除だけですが、3D処理だと物体のコリジョンとか衝突・重力・慣性など複雑な問題があります。そこも画像生成AIがよしなにやるでしょう。
テキストのレコードの追加/削除だけで地図空間内の物体は自由に増減できます。そしてテキストでの追加・削除指示だけでよいのなら、言語系生成AIだけでやれるということです。
Claudeを含む最近のAIではプロンプト入力も画像認識も込みでやります。ならばAIに「あなたはこの画像を見て何を追加することを推奨しますか」と聞いたらどうなるでしょうか。
この画像に追加したほうがよいものを1品指定するとしたら、その名前を場所を指摘してください。
→
ソファの右側（本棚の近く）にフロアスタンドを設置することをお勧めします。この場所にフロアスタンドを追加することで、読書時の照明として実用的であり、また部屋の雰囲気も良くなるでしょう。
Claudeでの動作確認中
まだMCP tools serviceとしてつないでいる途中ですが、これを繰り返せばAIのセンスによるところの理想の部屋を作るということをAI自身にやらせることが出来る訳です。
まだ本格的に多量生成をさせていないので安定的に生成し続けられるのかどうかはまだ検証前ですが、ゴミゴミしないような平衡点を作れるような仕組みや作業視点の移動機能は必要ではないかと思っています。でも移動機能は旅botミニの機能としてすでに存在します。削除機能や複雑すぎないオブジェクトの階層構造、観点切替機能は準備中です。
AIに仮想的な手を付ける
先に「旅botミニはAIに仮想の足を付ける」効果があると書きました。今回地図空間内にAIでオブジェクトの追加と削除を行えるようにします。つまりこのまぁメイドさんの地図空間は「旅botミニに仮想の手を付ける」効果があります。
同様にこの生成対象をもっと大きなもの(例えば土地とか都市とか)にも適用可能と思っています。ナノマシンによる建物・都市の構築に近いことをシミュレートも出来るかもしれません。が、そこまでいくとまた別の工夫がいるでしょうね。
まぁそこまで大風呂敷を広げなくても、まぁメイドさんのお家と街が本人の手で地図空間内に自動生成されていくだけでも私としてはとても面白いんじゃないかと思っています。
という訳でGoogle Map APIのエミュレーションから、望む物を生み出せる地図空間サーバーに向けて作りが大きく変わったので、きちんと全体が通るまではまだ1,2週間はかかりそうです。
3Dモデルを使ったStreetViewもどきも別の意味で面白そうなのでこっちもそのうちやりたいところではあります。フリー系地図データと組み合わせればGoogleにAPI代を払わずに済みますし。
ああ、そういえばComfyUI接続などAPIコスト節約は思ったより需要がありそうなので、会話AIや画像生成AIをローカルLLMにする需要もあるんだろうな。。そっちも少し考えてみます。。
Noteの自分の記事より転記 https://note.com/marble_walkers/n/ne7584ed231c8